I just come across a deadlock, probably on jedit exit.
Scenario seems like that:
1. XML parses the xml file (it was my active buffer), thus has the buffer locked
2. XML calls invokeAndWait indirectly through a call to VFSManager.waitForRequests,
from Resolver:597
3. AWT thread tries to acquire a lock for the buffer, but it's already taken by XML/sidekick
Looks like invokeAndWait call is illegal in this situation, when a buffer lock is
held.
Parts of deadlock dump attached.
| Submitted | jarekczek - 2012-05-27 - 15:35:45z | Assigned | kerik-sf |
|---|---|---|---|
| Priority | 5 | Category | None |
| Status | Pending | Group | None |
| Resolution | Fixed | Visibility | No |
| 2012-05-27 - 15:39:19z jarekczek |
Maybe my last activity was application switch, which caused buffer reload. |
|---|---|
| 2012-05-27 - 18:40:28z kerik-sf |
interesting. Thanks for the report with thread dumps. What version of XMLPlugin are you using ? |
| 2012-05-28 - 18:06:32z jarekczek |
r21502, reported as 2.8.2. Linux, sun java 6. The file that was presented during hang up was jedit/doc/users-guide/source-edit.xml I had more files open and I was doing some checkouts (in other non-jedit window), so probably more than one file was changed at the moment. I tried to closed jedit right-clicking on task-bar, and only then I noticed it was not responding. I checked that SideKick does buffer.readLock() immediately before passing control to a parser, through "parse" call. |
| 2012-05-29 - 15:11:23z jarekczek |
I am able to reproduce the bug now: 1. start trunk jedit with new settings dir (jars dir empty) 2. download xml and sidekick through pm 3. open jedit/doc/users-guide/shortcuts.xml 4. click yes to xml prompts 5. have sidekick docked at left and the xml tree should be visible there 6. open source-edit.xml 7. switch to a system terminal, "touch *" in doc dir 8. switch to jedit What happens is: 1. Buffer_loaded is fired for "shortcuts.xml" 2. It triggers xml parsing of "source-edit.xml" 3. Jedit tries to reload "source-edit.xml", but it is locked. There is an issue with sidekick, as it orders to parse a buffer when another buffer is being reloaded. But anyway xml plugin could be resistant to such tricky commands and not enter a deadlock state. I tried hard to reproduce the deadlock using manual parsing, caused by buffer switcher or induced by typing. No luck. Gui is blocked since the parser starts its job. A quick thought: if gui is always locked during parsing, the deadlock should be easily avoided by doing all parsing in edt. But SideKick makes it hard as it acquires readLock before passing control to the parser. |
| 2012-05-29 - 17:08:36z jarekczek |
Simpler recipe which does not involve any sidekick vulnerabilities, purely xml: 1. Open source-edit.xml 2. Have a shortcut for "Reload" 3. Do quickly 2 consecutive reloads. I discovered it trying to figure out why the gui is blocked during the parsing. I was wrong. It is not blocked. Maybe I screwed up the code somewhere. Now the gui is responsive during parsing and that enables to reproduce the deadlock easily. Initially I was reproducing the deadlock inserting computational delay (a new api from r21735, org.gjt.sp.jedit.Debug.compDelay(3000)) in SideKick, but finally it turned out that it is possible also with bare hands. |
| 2013-04-07 - 18:49:12z kerik-sf |
committed a fix in r22925. At this point all calls to buffer.readLock and SwingUtilities.invokeAndWait are protected by a timeout to interrupt the background parsing. |
| 2013-05-01 - 09:38:13z kerik-sf |
to be closed upon release 2.8.5 |
| 2012-05-27 - 15:38:35z jarekczek |
xml_deadlock 2 parts of deadlock dump |
|---|